<html>
<head>
<title> System Management & Security </title>
<link rel="stylesheet" type="text/css" href="css/html.css">
<link rel="stylesheet" type="text/css" href="css/docbook.css">
<link rel="stylesheet" type="text/css" href="css/syntax.css">
<link rel="stylesheet" type="text/css" href="css/regular_table.css">
</head>


<body>
<h1> 6 Files / Inodes </h1>

<div class="TOC">
<dl>
<dt><b>Table of Contents</b></dt>
<dt>6.1  <a href="chapter6.html#FILES">           Files                         </a></dt>
<dt>6.2  <a href="chapter6.html#TEXT_FILES">      Text Files                    </a></dt>
<dt>6.3  <a href="chapter6.html#NEWLINE">         Newline                       </a></dt>
<dt>6.4  <a href="chapter6.html#PROG_FILES">      C programming with files      </a></dt>
<dt>6.5  <a href="chapter6.html#FILE_DESCRIPTORS">Standard File Descriptors     </a></dt>
<dt>6.6  <a href="chapter6.html#INODE">           The Inode                     </a></dt>
<dt>6.7  <a href="chapter6.html#STAT">            The stat() system call        </a></dt>
<dt>6.8  <a href="chapter6.html#TYPE">            The File Type                 </a></dt>
<dt>6.9  <a href="chapter6.html#PROTECT">         The Protection Bits           </a></dt>
<dt>6.10 <a href="chapter6.html#STICKY">          The Sticky Bit                </a></dt>
<dt>6.11 <a href="chapter6.html#SETUID">          The Setuid Bit                </a></dt>
<dt>6.12 <a href="chapter6.html#SETGID">          The Setgid Bit                </a></dt>
<dt>6.13 <a href="chapter6.html#HARD_LINKS">      Hard Links                    </a></dt>
<dt>6.14 <a href="chapter6.html#SYMB_LINKS">      Symbolic Links                </a></dt>
<dt>6.15 <a href="chapter6.html#HARD_SOFT">       Hard Links and Symbolic Links </a></dt>
</dl>
</div>

<!------------------ 6.1 Files ---------------------------------------->
<div class="SECT1">
<h1 class="SECT1"><a id="FILES" name="FILES">6.1 Files</a></h1>
<p>
<ul>
<li>abstraction from hardware (device, head, cylinder, sector)</li>
<li>call file by a file name </li>
<li>directory hierarchy</li>
<ul>
<li>is a tree with root  <tt class="FILENAME"><b>/</b></tt></li>
<li>subdirectories separated by "/", e.g.  <tt class="FILENAME">/home/bfriedrich</tt></li>
<li>valid directory name is a path in the tree, e.g. <kbd class="USERINPUT">cd </kbd><tt class="FILENAME">/home/bfriedrich</tt></li>
</ul>
<li>but a file name is unsuitable for a program thus there are several ways to access files within a program:</li>
<ul>
<li>system level: file descriptor = int</li>
<li>C library level: file pointer = FILE *</li>
<li>C++ library level: file stream class = fstream</li>
<li>Java: file stream class = FileReader/Writer</li>
</ul>
</ul>
</p>
</div>


<!------------------ 6.2 Text Files ---------------------------------------->
<div class="SECT2">
<h1 class="SECT2"><a id="TEXT_FILES" name="TEXT_FILES">6.2 Text Files</a></h1>
<p>
A text file consists of zero or more lines. Each line is terminated by a newline. Notice that also
the last line must be terminated by a newline. Some programs have problems processing the last line
of a file if it isn't newline terminated, e.g. the command <kbd class="USERINPUT">wc -l</kbd> does
not work correctly if the last line does not have a newline. In this case you can symply open and save
the file with the editor <b>vi</b> which terminates each line by a newline.
</p>
</div>


<!------------------ 6.3 Newline ---------------------------------------->
<div class="SECT3">
<h1 class="SECT3"><a id="NEWLINE" name="NEWLINE">6.3 Newline</a></h1>

<p>
In computing, a newline is a special character or sequence of characters signifying the end of a
line of text. The actual codes representing a newline vary across hardware platforms and operating
systems, which can be a problem when exchanging data between systems with different representations.
</p>

<p>
There is also some confusion whether newlines terminate or separate lines. If a newline is considered
a separator, there will be no newline after the last line of a file. The general convention on most
systems is to add a newline even after the last line, i.e., to treat newline as a line terminator.
Some programs have problems processing the last line of a file if it isn't newline terminated.
Conversely, programs that expect newline to be used as a separator will interpret a final newline
as starting a new (empty) line. This can result in a different line count being reported for the file,
but is otherwise generally harmless.
</p>

<p>
Systems based on ASCII or a compatible character set use either LF (Line feed, 0x0A) or CR (Carriage Return, 0x0D) individually, or CR followed by LF (CR+LF, 0x0D 0x0A). These characters are based on printer commands: The line feed indicated that one line of paper should feed out of the printer, and a carriage return indicated that the printer carriage should return to the beginning of the current line.
</p>

<ul>
<li><b>LF</b>&nbsp;&nbsp;&nbsp;Multics, Unix and Unix-like systems (GNU/Linux, AIX, Xenix, Mac OS X, FreeBSD, etc.), BeOS, Amiga, RISC OS, and others</li>
<li><b>CR+LF</b>&nbsp;&nbsp;&nbsp;DEC RT-11 and most other early non-Unix, non-IBM OSes, CP/M, MP/M, DOS, OS/2, Microsoft Windows, Symbian OS</li>
<li><b>CR</b>&nbsp;&nbsp;&nbsp;Commodore machines, Apple II family, Mac OS up to version 9 and OS-9</li>
</ul>

<p>
The Unicode standard defines a large number of characters that conforming applications should recognize as line terminators:
</p>

<pre>
LF:    Line Feed, U+000A
CR:    Carriage Return, U+000D
CR+LF: CR followed by LF, U+000D followed by U+000A
NEL:   Next Line, U+0085
FF:    Form Feed, U+000C
LS:    Line Separator, U+2028
PS:    Paragraph Separator, U+2029
</pre>

<p>
The different newline conventions often cause text files that have been transferred between systems of different types to be displayed incorrectly. For example, files originating on Unix or Apple Macintosh systems may appear as a single long line on a Windows system. Conversely, when viewing a file from a Windows computer on a Unix system, the extra CR may be displayed as &circ;M at the end of each line or as a second line break.
</p>

<p>
The File Transfer Protocol can automatically convert newlines in files being transferred between systems with different newline representations when the transfer is done in &quot;ASCII mode&quot;. However, transferring binary files in this mode usually has disastrous results: Any occurrence of the newline byte sequence which does not have line terminator semantics in this context, but is just part of a normal sequence of bytes will be translated to whatever newline representation the other system uses, effectively corrupting the file. FTP clients often employ some heuristics (for example, inspection of filename extensions) to automatically select either binary or ASCII mode, but in the end it is up to the user to make sure his files are transferred in the correct mode. If there is any doubt as to the correct mode, binary mode should be used, as then no files will be altered by FTP, though they may display incorrectly.
</p>

<small>
Reference <a href="http://en.wikipedia.org/wiki/Newline">Wikipedia: Newline</a>
</small>
</div>

<!------------------ 6.4 C programming with files  ---------------------------------------->
<div class="SECT4">
<h1 class="SECT4"><a id="PROG_FILES" name="PROG_FILES">6.4 C programming with files</a></h1>
<p>

<div class="CODELISTING">
<pre>
<span class="lnr"> 1 </span><span class="PreProc">#include </span><span class="Constant">&lt;sys/types.h&gt;</span>
<span class="lnr"> 2 </span><span class="PreProc">#include </span><span class="Constant">&lt;sys/stat.h&gt;</span>
<span class="lnr"> 3 </span><span class="PreProc">#include </span><span class="Constant">&lt;fcntl.h&gt;</span>
<span class="lnr"> 4 </span><span class="PreProc">#include </span><span class="Constant">&lt;stdio.h&gt;</span>
<span class="lnr"> 5 </span><span class="PreProc">#include </span><span class="Constant">&lt;unistd.h&gt;</span>
<span class="lnr"> 6 </span>
<span class="lnr"> 7 </span><span class="Comment">/*</span><span class="Comment">*</span>
<span class="lnr"> 8 </span><span class="Comment"> *  Writes &quot;hello world&quot; in the given file </span>
<span class="lnr"> 9 </span><span class="Comment"> * </span>
<span class="lnr">10 </span><span class="Comment"> *  name    file_hello_world.c</span>
<span class="lnr">11 </span><span class="Comment"> *  version 1.0</span>
<span class="lnr">12 </span><span class="Comment"> *  author  Prof. Dr.-Ing. Damian Weber (dweber@htw-saarland.de)</span>
<span class="lnr">13 </span><span class="Comment"> </span><span class="Comment">*/</span>
<span class="lnr">14 </span><span class="Type">int</span> main(<span class="Type">int</span> numberOfArguments, <span class="Type">char</span> **arguments)
<span class="lnr">15 </span>{
<span class="lnr">16 </span>  <span class="Statement">if</span>(numberOfArguments &lt;= <span class="Constant">1</span>)
<span class="lnr">17 </span>  {
<span class="lnr">18 </span>    <span class="Statement">return</span> <span class="Constant">1</span>;
<span class="lnr">19 </span>  }
<span class="lnr">20 </span>
<span class="lnr">21 </span>  <span class="Comment">/*</span><span class="Comment"> Opens or creates a file for reading or writing. If successful, open() returns a non-negative integer, termed a file</span>
<span class="lnr">22 </span><span class="Comment">     descriptor. It returns -1 on failure, and sets errno to indicate the error. </span><span class="Comment">*/</span>
<span class="lnr">23 </span>  <span class="Type">int</span> fileDescriptor =  open(arguments[<span class="Constant">1</span>],       <span class="Comment">/*</span><span class="Comment"> file name </span><span class="Comment">*/</span>
<span class="lnr">24 </span>                             O_CREAT | O_WRONLY, <span class="Comment">/*</span><span class="Comment"> O_CREAT  - create file if it does not exist </span>
<span class="lnr">25 </span><span class="Comment">                                                    O_WRONLY - open for writing only </span>
<span class="lnr">26 </span><span class="Comment">                                                    The bitwise or-operation &quot;|&quot;  allows to combine both. </span><span class="Comment">*/</span>
<span class="lnr">27 </span>                             S_IRUSR | S_IWUSR); <span class="Comment">/*</span><span class="Comment"> chmod-flags: The file is created with the given chmod-flags AND (!!!) </span>
<span class="lnr">28 </span><span class="Comment">                                                    modified by the umask process</span>
<span class="lnr">29 </span><span class="Comment">                                                    S_IRUSR 0000400    R for owner</span>
<span class="lnr">30 </span><span class="Comment">                                                    S_IWUSR 0000200    W for owner</span>
<span class="lnr">31 </span><span class="Comment">                                                    =&gt; chmod sets &quot;rw-&quot; for owner by the created file (don't forget umask!) </span><span class="Comment">*/</span>
<span class="lnr">32 </span>  <span class="Statement">if</span>(fileDescriptor &lt; <span class="Constant">0</span>)
<span class="lnr">33 </span>  {
<span class="lnr">34 </span>    perror(<span class="Constant">&quot;open()&quot;</span>);
<span class="lnr">35 </span>    <span class="Statement">return</span> <span class="Constant">1</span>;
<span class="lnr">36 </span>  }
<span class="lnr">37 </span>
<span class="lnr">38 </span>  <span class="Comment">/*</span><span class="Comment"> Writes &quot;hello worldn&quot; (12 bytes) to the file referenced by fileDescriptor. On success it returns the number of bytes which are </span>
<span class="lnr">39 </span><span class="Comment">     written. Otherwise a -1 is returned and the global variable errno is set. </span><span class="Comment">*/</span>
<span class="lnr">40 </span>  <span class="Statement">if</span>(write(fileDescriptor, <span class="Constant">&quot;hello world</span><span class="Special">n</span><span class="Constant">&quot;</span>, <span class="Constant">12</span>) &lt; <span class="Constant">0</span>)
<span class="lnr">41 </span>  {
<span class="lnr">42 </span>    perror(<span class="Constant">&quot;write()&quot;</span>);
<span class="lnr">43 </span>    <span class="Statement">return</span> <span class="Constant">1</span>;
<span class="lnr">44 </span>  }
<span class="lnr">45 </span>
<span class="lnr">46 </span>  <span class="Comment">/*</span><span class="Comment"> The close() function deletes &quot;fileDesciptor&quot; and  returns the value 0 if successful; otherwise close() returns the value -1 </span>
<span class="lnr">47 </span><span class="Comment">     and sets the global variable errno.</span><span class="Comment">*/</span>
<span class="lnr">48 </span>  <span class="Statement">if</span>(close(fileDescriptor) &lt; <span class="Constant">0</span>)
<span class="lnr">49 </span>  {
<span class="lnr">50 </span>    perror(<span class="Constant">&quot;close()&quot;</span>);
<span class="lnr">51 </span>    <span class="Statement">return</span> <span class="Constant">1</span>;
<span class="lnr">52 </span>  }
<span class="lnr">53 </span>
<span class="lnr">54 </span>  <span class="Statement">return</span> <span class="Constant">0</span>;
<span class="lnr">55 </span>}
</pre>
</div>

</p>
</div>



<!------------------ 6.5 Standard File Descriptors------------------------------------>
<div class="SECT5">
<h1 class="SECT5"><a id="FILE_DESCRIPTORS" name="FILE_DESCRIPTORS">6.5 Standard File Descriptors</a></h1>

<p><b>Figure 6-1. Simple diagram of Unix and C standard streams (stdio) (source:
<a href="http://commons.wikimedia.org/wiki/File:Stdstreams-notitle.svg">wikipedia</a>)</b></p>
<img src="img/stdstreams.png">
<p>
Generally, a file descriptor is an index for an entry in a kernel-resident data structure containing
the details of all open files. In POSIX this data structure is called a file descriptor table, and
each process has its own file descriptor table. The user application passes the abstract key to the
kernel through a system call, and the kernel will access the file on behalf of the application, based
on the key. The application itself cannot read or write the file descriptor table directly.
</p>
<p>
In Unix-like systems, file descriptors can refer to files, directories, block or character devices
(also called "special files"), sockets, FIFOs (also called named pipes), or unnamed pipes.
</p>
<p>
The FILE * file handle in the C standard I/O library routines is technically a pointer to a data
structure managed by those library routines; one of those structures usually includes an actual low
level file descriptor for the object in question on Unix-like systems. Since file handle refers to
this additional layer, it is not interchangeable with file descriptor.
</p>

<p><b>Table 6-1. Standard File Descriptors</b></p>

<table>

<tr>
<th> Descriptor </th>
<th> FILE *     </th>
<th> meaning    </th>
<th> device     </th>
<tr>

<tr>
<td>0             </td>
<td>stdin         </td>
<td>standard input</td>
<td>keyboard      </td>
</tr>

<tr>
<td>1              </td>
<td>stdout         </td>
<td>standard output</td>
<td>terminal       </td>
</tr>

<tr>
<td>2              </td>
<td>stderr         </td>
<td>standard error </td>
<td>terminal       </td>
</tr>

</table>

<p>
These file descriptors can be redirected on the shell:
</p>

<div class="CODELISTING">
<pre>
# <b>&lt;</b> redirects the standard input
$ while read line; do echo $line; done &lt; $file

# <b>&gt;</b> redirects the standard output to a file
$ man stdio &gt; file

# <b>&gt;&gt;</b> redirects the standard output, appends to file
$ echo "$(date) : something happened"       >> log_file
$ echo "$(date) : something happened again" >> log_file
$ cat log_file
#    So 25. Jan 13:44:46 CET 2009 : something happened
#    So 25. Jan 13:46:09 CET 2009 : something happened again


# <b>2&gt;</b> redirects the standard error
$ (echo 'Oho!' &gt;&2) 2> error_log
$ cat error_log
Oho!
</pre>
</div>

<small>
Reference <a href="http://en.wikipedia.org/wiki/File_descriptor">Wikipedia: File descriptor</a>
</small>
</div>


<!------------------ 6.6 The Inode ---------------------------------------->
<div class="SECT6">
<h1 class="SECT6"><a id="INODE" name="INODE">6.6 The Inode</a></h1>
<img src="img/inode.png">
<p>
Each disk drive contains some number of file systems.  A file system
consists of a number of cylinder groups.  Each cylinder group has inodes and
data.
<br><br>
A file system is described by its super-block, which in turn describes
the cylinder groups.  The super-block is critical data and is replicated
in each cylinder group to protect against catastrophic loss.  This is
done at file system creation time and the critical super-block data does
not change, so the copies need not be referenced further unless disaster
strikes.
<br><br>
Addresses stored in inodes are capable of addressing fragments of
"blocks".	File system blocks can be optionally
broken into 2, 4, or 8 pieces, each of which is addressable.
<br><br>
Large files consist of exclusively large data blocks.  To avoid undue
wasted disk space, the last data block of a small file is allocated as
only as many fragments of a large block as are necessary.	The file
system format retains only a single pointer to such a fragment, which is a
piece of a single large block that has been divided.
<br><br>
The file system records space availability at the fragment level; to
determine block availability, aligned fragments are examined.
<br><br>
The root inode is the root of the file system.  Inode 0 cannot be used
for normal purposes and historically bad blocks were linked to inode 1,
thus the root inode is 2 (inode 1 is no longer used for this purpose,
however numerous dump tapes make this assumption).
<br><br>
In summary, we can say that a inode contains administrative data of a file.
You can read its data easily by the stat() system call. For more details of stat,
have a look at the text below.
</p>

<small>
Reference <a href="http://www.freebsd.org/cgi/man.cgi?query=inode&apropos=0&sektion=0&manpath=FreeBSD+7.1-RELEASE&format=html">inode manual page</a>
</small>
</div>


<!------------------ 6.7 The stat() system call ---------------------------------------->
<div class="SECT7">
<h1 class="SECT7"><a id="STAT" name="STAT">6.7 The stat() system call</a></h1>
<p>
The <i>stat()</i> system call obtains information about the file pointed to by
path.  Read, write or execute permission of the named file is not
required, but all directories listed in the path name leading to the file
must be searchable.
<br><br>
The <i>lstat()</i> system call is like stat() except in the case where the named
file is a symbolic link, in which case lstat() returns information about
the link, while stat() returns information about the file the link refer-
ences.
<br><br>
The <i>fstat()</i> system call obtains the same information about an open file
known by the file descriptor fd.
<br><br>
The sb argument is a pointer to a stat structure as defined by
&lt;<i>sys/stat.h</i>&gt; and into which information is placed concerning the file.
<br><br>
Upon successful completion, the value 0 is returned; otherwise the
value -1 is returned and the global variable errno is set to indicate the
error. For further details have a look at the
<a href="http://www.freebsd.org/cgi/man.cgi?query=lstat&sektion=2&apropos=0&manpath=FreeBSD+7.1-RELEASE">STAT(2) manual page</a>.
</p>

<div class="CODELISTING">
<pre>
	<span class="lnr"> 1 </span><span class="PreProc">#include </span><span class="Constant">&lt;sys/types.h&gt;</span>
	<span class="lnr"> 2 </span><span class="PreProc">#include </span><span class="Constant">&lt;sys/stat.h&gt;</span>
	<span class="lnr"> 3 </span>
	<span class="lnr"> 4 </span><span class="Type">int</span>  stat(<span class="Type">const</span> <span class="Type">char</span> *path, <span class="Type">struct</span> stat *sb);
	<span class="lnr"> 5 </span><span class="Type">int</span> lstat(<span class="Type">const</span> <span class="Type">char</span> *path, <span class="Type">struct</span> stat *sb);
	<span class="lnr"> 6 </span><span class="Type">int</span> fstat(<span class="Type">int</span> fd,           <span class="Type">struct</span> stat *sb);
	<span class="lnr"> 7 </span>
	<span class="lnr"> 8 </span><span class="Type">struct</span> stat {
	<span class="lnr"> 9 </span>    ino_t     st_ino;     <span class="Comment">/*</span><span class="Comment"> inode                         </span><span class="Comment">*/</span>
	<span class="lnr">10 </span>    dev_t     st_dev;     <span class="Comment">/*</span><span class="Comment"> device of this file           </span><span class="Comment">*/</span>
	<span class="lnr">11 </span>    mode_t    st_mode;    <span class="Comment">/*</span><span class="Comment"> protection + file type        </span><span class="Comment">*/</span>
	<span class="lnr">12 </span>    nlink_t   st_nlink;   <span class="Comment">/*</span><span class="Comment"> number of hard links          </span><span class="Comment">*/</span>
	<span class="lnr">13 </span>    uid_t     st_uid;     <span class="Comment">/*</span><span class="Comment"> user ID of owner              </span><span class="Comment">*/</span>
	<span class="lnr">14 </span>    gid_t     st_gid;     <span class="Comment">/*</span><span class="Comment"> group ID of owner             </span><span class="Comment">*/</span>
	<span class="lnr">15 </span>    dev_t     st_rdev;    <span class="Comment">/*</span><span class="Comment"> device type (if inode device) </span><span class="Comment">*/</span>
	<span class="lnr">16 </span>    <span class="Type">off_t</span>     st_size;    <span class="Comment">/*</span><span class="Comment"> total size, in bytes          </span><span class="Comment">*/</span>
	<span class="lnr">17 </span>    blksize_t st_blksize; <span class="Comment">/*</span><span class="Comment"> blocksize for filesystem I/O  </span><span class="Comment">*/</span>
	<span class="lnr">18 </span>    blkcnt_t  st_blocks;  <span class="Comment">/*</span><span class="Comment"> number of blocks allocated    </span><span class="Comment">*/</span>
	<span class="lnr">19 </span>    <span class="Type">time_t</span>    st_atime;   <span class="Comment">/*</span><span class="Comment"> time of last access           </span><span class="Comment">*/</span>
	<span class="lnr">20 </span>    <span class="Type">time_t</span>    st_mtime;   <span class="Comment">/*</span><span class="Comment"> time of last modification     </span><span class="Comment">*/</span>
	<span class="lnr">21 </span>    <span class="Type">time_t</span>    st_ctime;   <span class="Comment">/*</span><span class="Comment"> time of last file status (inode data) modification </span><span class="Comment">*/</span>
	<span class="lnr">22 </span>};
</pre>
</div>

<small>
Reference <a href="http://www.freebsd.org/cgi/man.cgi?query=lstat&sektion=2&apropos=0&manpath=FreeBSD+7.1-RELEASE">stat manual page</a>
</small>
</div>


<!------------------ 6.8 The File Type ---------------------------------------->
<div class="SECT8">
<h1 class="SECT8"><a id="TYPE" name="TYPE">6.8 The File Type</a></h1>

<table>

<tr>
<th > type         </th>
<th> description  </th>
<th> mnemonic     </th>
<tr>

<tr>
<td> regular file </td> 
<td> "normal" file with user data or program</td>
<td> - </td>
</tr>

<tr>
<td> directory </td> 
<td>contains file names pointing to their inodes</td>
<td> d </td>
</tr>

<tr>
<td> link </td> 
<td> points to another file</td>
<td> l </td>
</tr>

<tr>
<td> socket </td> 
<td> UNIX domain socket, process communication</td>
<td> s </td>
</tr>

<tr>
<td> pipe </td> 
<td> process communication</td>
<td> p </td>
</tr>

<tr>
<td> block device </td> 
<td> device handling data in blocks </td>
<td> b </td>
</tr>

<tr>
<td> character device </td> 
<td> device handling data char by char</td>
<td> c </td>
</tr>

</table>

<p>
</p>
</div>



<!------------------ 6.9 The Protection Bits ---------------------------------------->
<div class="SECT9">
<h1 class="SECT9"><a id="PROTECT" name="PROTECT">6.9 The Protection Bits</a></h1>
<p>
The system can handle several users all working simultaneously on completely unrelated tasks. The 
system is responsible for properly sharing and managing requests for hardware devices, peripherals, 
memory, and CPU time fairly to each user.
Because the system is capable of supporting multiple users, everything the system manages has a set 
of permissions governing who can read, write, and execute the resource. These permissions are stored 
as three octets broken into three pieces, one for the owner of the file, one for the group that the 
file belongs to, and one for everyone else.
</p>

<table>

<tr>
<th>Value</th>
<th>Permission</th>
<th>Directory Listing</th>
</tr>

<tr>
<td>0</td>
<td>No read, no write, no execute</td>
<td><tt class="LITERAL">---</tt></td>
</tr>

<tr>
<td>1</td>
<td>No read, no write, execute</td>
<td><tt class="LITERAL">--x</tt></td>
</tr>

<tr>
<td>2</td>
<td>No read, write, no execute</td>
<td><tt class="LITERAL">-w-</tt></td>
</tr>

<tr>
<td>3</td>
<td>No read, write, execute</td>
<td><tt class="LITERAL">-wx</tt></td>

</tr>

<tr>
<td>4</td>
<td>Read, no write, no execute</td>
<td><tt class="LITERAL">r--</tt></td>
</tr>

<tr>
<td>5</td>
<td>Read, no write, execute</td>
<td><tt class="LITERAL">r-x</tt></td>

</tr>

<tr>
<td>6</td>
<td>Read, write, no execute</td>
<td><tt class="LITERAL">rw-</tt></td>
</tr>

<tr>
<td>7</td>
<td>Read, write, execute</td>
<td><tt class="LITERAL">rwx</tt></td>
</tr>

</table>

<br>
<img src="img/protection_bits.png">

<p>
When you create a new file, you will notice, there is a default protection. It is possible to influences 
this default protection by using the command umask. umask performs a xor operation with the given 
octal-coded mask and the octal code 777. 
<b>Note:</b> The x-bit is omitted for non-directories, regardless of the umask.
</p>

<div class="CODELISTING">
<pre>
# sets the umask 027 as default protection
# rwx rwx rwx
# 000 010 111
#  0   2   7

$ umask 027

# umask influences the protection by xor with 777, so:
# 777 xor 027:
# 
#     111 111 111
# xor 000 010 111 (umask)
# =   111 101 000
# =   rwx r-x --- (resulting default protection of a new file)

$ touch <tt class="FILENAME">new_file</tt>
$ ls -l <tt class="FILENAME">new_file</tt>
-rw-r----- 1 bfriedrich bfriedrich 0 2009-03-12 21:34 <tt class="FILENAME">new_file</tt>

$ mkdir  <tt class="FILENAME">new_dir</tt>
$ ls -ld <tt class="FILENAME">new_dir</tt>
drwxr-x--- 2 bfriedrich bfriedrich 4096 2009-03-12 21:36 <tt class="FILENAME">new_dir</tt>
</pre>
</div>

<p> 
Of course umask is not the only way to influence the protection of a file. If you want to change
the protection of an existing file, you must use the command chmod. The following listing shows
how to use chmod. For further deatils have a look at 
<a href="http://www.freebsd.org/cgi/man.cgi?query=chmod&apropos=0&sektion=1&manpath=FreeBSD+7.1-RELEASE&format=html">CHMOD(1)</a>. 
</p>

<div class="CODELISTING">
<pre>
$ ls -l <tt class="FILENAME">new_file</tt>
-rw-r----- 1 bfriedrich bfriedrich 0 2009-03-12 21:34 <tt class="FILENAME">new_file</tt>

# Sets the protection bits with an octal code
$ chmod 644 <tt class="FILENAME">new_file</tt>
$ ls -l <tt class="FILENAME">new_file</tt>
-rw-r--r-- 1 bfriedrich bfriedrich 0 2009-03-12 21:34 <tt class="FILENAME">new_file</tt>

# Alternatively you can use
$ chmod o+r <tt class="FILENAME">new_file</tt>
# to get the same effect.
</pre>
</div>

<p>
The right interpretation of the protection bits is a little tricky. 
For example:
</p>
<div class="CODELISTING">
<pre>
$ ls -l <tt class="FILENAME">new_file</tt>
-rw-r--r-- 1 bfriedrich bfriedrich 0 2009-03-12 21:34 <tt class="FILENAME">new_file</tt>
</pre>
</div>
<p>
This presentation shows us the protection bits of <tt class="FILENAME">new_file</tt>. 
The owner is the only one who has the w-bit set. So, other peole can not write into it,
but this does not mean, other people can not delete it! The protection bits of a file
does only determine the protection of the file content. For this reason you have to consider 
the protection bits of the parent directory. The following listing shows you how to interprete
the protection bits of a directory.
</p>

<div class="CODELISTING">
<pre>
$ chmod 000 new_dir
$ ls -ld new_dir
d--------- 2 bfriedrich bfriedrich 4096 2009-03-12 21:36 new_dir

$ls -l new_dir
ls: Permission denied

$cd new_dir
bash: cd: new_dir: Permission denied

$echo 'test' > new_dir/another_new_file
bash: new_dir/another_new_file: Permission denied

# makes the directory readable, so you can (only) read the file names in it
$ chmod 444 new_dir
$ ls -ld new_dir
dr--r--r-- 2 bfriedrich bfriedrich 4096 2009-03-12 23:01 new_dir

ls -l new_dir
ls: new_dir/file1: Permission denied
ls: new_dir/file2: Permission denied
total 0
-????????? ? ? ? ?                ? file1
-????????? ? ? ? ?                ? file2

# although the read bit is set, you can not read the file content
$ cat new_dir/file1
cat: new_dir/file1: Permission denied

# this is beacause the search path is not allowed.
# you can fix this by setting execute bit:
$ chmod 555 new_dir
$ ls -ld new_dir
dr-xr-xr-x 2 bfriedrich bfriedrich 4096 2009-03-12 23:01 new_dir
$ cd new_dir
$ cat file1
content of file1

# if you set the write bit, you can create and replace files in this directory.
# but this makes only sense, if the execute bit is set, otherwise you can not
# access the directory path and so you can neither create nor replace something
# in it.
$ chmod 777 new_dir
$ ls -ld new_dir
drwxrwxrwx 2 bfriedrich bfriedrich 4096 2009-03-12 23:01 new_dir

$ cd new_dir
$ ls -l
total 0
-rw-r----- 1 bfriedrich bfriedrich 0 2009-03-12 23:00 file1
-rw-r----- 1 bfriedrich bfriedrich 0 2009-03-12 23:01 file2

$ rm *; echo "I have removed all files...and I am not the owner :-P"
I have removed all files...and I am not the owner :-P

$ ls -l
total 0

</pre>
</div>


<!------------------ 6.10 The Special Protection Bits ---------------------------------------->
<div class="SECT10">
<h1 class="SECT10"><a id="STICKY" name="STICKY">6.10 The Sticky Bit</a></h1>
<p>
The sticky bit is an access-right flag that can be assigned to files and directories on Unix systems.
The most common use of the sticky bit today is on directories, where, when set, items inside the directory 
can be renamed or deleted only by the item's owner, the directory's owner, or the superuser.
</p>
<p>
Without the sticky bit, anyone able to write to the directory can delete or rename files. The
sticky bit is commonly found on directories, such as <tt class="FILENAME">/tmp</tt>, that are 
world-writable.
</p>
<p>
The sticky bit set by a leading 1 in the chmod calls.
</p>

<div class="CODELISTING">
<pre>
mkdir testdir
chmod 777 testdir
$ ls -ld testdir
drwxrwxrw<b>x</b> 2 bfriedrich bfriedrich 4096 2009-03-23 16:57 testdir

# sets the sticky bit on testdir
$ chmod <b>1</b>777 testdir
$ ls -ld testdir
drwxrwxrw<b>t</b> 2 bfriedrich bfriedrich 4096 2009-03-23 16:52 testdir
</pre>
</div>
<small>
Reference <a href="http://en.wikipedia.org/wiki/Sticky_bit">Wikipedia: Sticky bit</a>
</small>
</div>


<!------------------ 6.11 The Setuid Bit ---------------------------------------->
<div class="SECT11">
<h1 class="SECT11"><a id="SETUID" name="SETUID">6.11 The Setuid Bit</a></h1>
<p>
setuid (short for set user ID upon execution) is an Unix access right flag that allow users to run 
an executable with the permissions of the  executable's owner. They are often used to allow users 
on a computer system to run programs with temporarily elevated privileges in order to perform a 
specific task. 
</p>
<p>
setuid is needed for tasks that require higher privileges than those which a common user 
has, such as changing the user's login password. Some of the tasks that require elevated privileges 
may not immediately be obvious, though — such as the ping command, which must send and listen for 
control packets on a network interface.
</p>
<p>
When a binary executable file has been given the setuid attribute, normal users on the system can 
execute this file and gain the privileges of the user who owns the file (commonly root) within the 
created process. When root privileges have been gained within the process, the application can then 
perform tasks on the system that regular users normally would be restricted from doing.  
Due to the increased likelihood of security flaws, many operating systems ignore the setuid attribute 
when applied to executable shell scripts.
</p>
<p>
While this setuid feature is very useful in many cases, it can pose a security risk if the setuid 
attribute is assigned to executable programs that are not carefully designed. Users can exploit
vulnerabilities in flawed programs to gain permanent elevated privileges, or unintentionally execute 
a trojan horse program.
</p>
<p>
In addition there is an another problem with the Setuid Bit. If you look at the file <tt class="FILENAME">/etc/master.passwd</tt>
on BSD (<tt class="FILENAME">/etc/shadow</tt> on Linux) which contains encrypted user passwords, such as:
</p>

<div class="CODELISTING">
<pre>
-rw------- root wheel /etc/master.passwd

root:$1$TeLs7PIX$ebgD6bh573GWHN12Aaut5/:0:0::0:0:root:/root:/bin/csh
sysi40:$1$dIQvGCrn$f46M9fNfWTmOVsyfQEwdu0:2040:1000::0:0:........:/home/sysi40:/usr/local/bin/bash
</pre>
</div>

<p>
Now, the user sysi40 wants to change his password. Therefore he needs write access to 
<tt class="FILENAME">/etc/master.passwd</tt>. But if he had write access, he could change
root's password too. So how does the command <kbd class="USERINPUT">chgpasswd</kbd> handle
this problem? The solution is each process has two User-IDs:
</p>

<ul>
<li><b>RUID:</b> real User-ID - who starts the process</li>
<li><b>EUID:</b> effective User-ID - decides about file access</li>
</ul>

<p>
Normally RUID is equal to EUID. But if the Setuid Bit is set on a program, the EUID is the UID
of the program owner.
</p>

<p>
If you look now at <kbd class="USERINPUT">chgpasswd</kbd> and <tt class="FILENAME">/etc/master.passwd</tt>
you have a better idea of how <kbd class="USERINPUT">chgpasswd</kbd> works:
</p>

<div class="CODELISTING">
<pre>
-r-sr-xr-x root wheel /usr/bin/passwd
-rw------- root wheel /etc/master.passwd
</pre>
</div>

<p>
You can recognize the following facts:
</p>

<ul>
  <li>/etc/master.passwd owner root, protection rw------- </li>
  <li>program passwd can change one line in /etc/master.passwd</li>
  <li>program passwd is owned by root      </li>                                                
  <li>program passwd has the setuid bit</li>
  <li>sysi40 starts program passwd</li>
  <li>process passwd has RUID=sysi40, EUID=root</li>
  <li>so for this process the rw- part counts</li>
</ul>

<p>
The Setuid Bit is set by a leading 4 in the <kbd class="USERINPUT">chmod</kbd> 
calls.
</p>

<div class="CODELISTING">
<pre>
$ chmod 755 my_program
$ ls -l my_program
-rwxr-xr-x    1 dw      users 255996 Jan 17 18:38 my_program

$ chmod <b>4</b>755 my_program
$ ls -l my_program
-rw<b>s</b>r-xr-x    1 dw      users 255996 Jan 17 18:38 my_program
</pre>
</div>
<small>
Reference <a href="http://en.wikipedia.org/wiki/Setuid">Wikipedia: Setuid Bit</a>
</small>
</div>


<!------------------ 6.12 The Setgid Bit ---------------------------------------->
<div class="SECT12">
<h1 class="SECT12"><a id="SETGID" name="SETGID">6.12 The Setgid Bit</a></h1>
<p>
The same mechanism holds for the GID field of the protection. 
We have:
</p>

<ul>
<li><b>RGID</b> the real GID</li>
<li><b>EGID</b> the effective GID</li>
</ul>

<p>
The Setgid Bit is set by a leading 2 in the chmod calls:
</p>

<div class="CODELISTING">
<pre>
$ chmod <b>2</b>755 my_other_program
$ ls -l my_other_program
-rwxr-<b>s</b>r-x    1 dw       users 1723139 Feb 15 15:11 my_other_program
</pre>
</div>
</div>


<!------------------ 6.13 Hard Links ---------------------------------------->
<div class="SECT13">
<h1 class="SECT13"><a id="HARD_LINKS" name="HARD_LINKS">6.13 Hard Links</a></h1>

<img src="img/hardlinks.png">
<p>
In computing, a hard link is a directory reference, or pointer, to a file on a storage volume. The 
name associated with the file is a label stored in a directory structure that refers the operating 
system to the file data. As such, more than one name can be associated with the same file. When 
accessed through different names, any changes made will affect the same file data.
</p>
<p>
The process of unlinking disassociates a name from the data on the volume without destroying the 
associated data. The data is still accessible as long as at least one link that points to it still 
exists. When the last link is removed, the space is considered free.
</p>

<small>
Reference <a href="http://en.wikipedia.org/wiki/Hard_link">Wikipedia:Hard link</a>
</small>
</div>


<!------------------ 6.14 Symbolic Links ---------------------------------------->
<div class="SECT14">
<h1 class="SECT14"><a id="SYMB_LINKS" name="SYMB_LINKS">6.14 Symbolic Links</a></h1>

<img src="img/softlinks.png">
<p>
In computing, a symbolic link (also symlink or soft link) is a special type of file that contains a 
reference to another file or directory in the form of an absolute or relative path and that affects 
pathname resolution.
</p>
<p>
Symbolic links operate transparently for most operations: programs which read or write to files 
named by a symbolic link will behave as if operating directly on the target file. However, programs 
that need to handle symbolic links specially (e.g., backup utilities) may identify and manipulate them 
directly.
</p>
<p>
A symbolic link merely contains a text string that is interpreted and followed by the operating 
system as a path to another file or directory. It is a file on its own and can exist independently 
of its target. If a symbolic link is deleted, its target remains unaffected. If the target is moved, 
renamed or deleted, any symbolic link that used to point to it continues to exist but now points to
a non-existing file.
<p>
Symbolic links exist in contrast to hard links. Hard links may not normally point to directories and
they can not link paths on different volumes. Symbolic links may point to any file or directory 
irrespective of the volumes on which the source and destination reside.
</p>
<small>
Reference <a href="http://en.wikipedia.org/wiki/Symbolic_link">Wikipedia:Symbolic link</a>
</small>
</div>


<!------------------ 6.15 Hard Links and Symbolic Links ---------------------------------------->
<div class="SECT15">
<h1 class="SECT15"><a id="HARD_SOFT" name="HARD_SOFT">6.15 Hard Links and Symbolic Links</a></h1>

<table>

<tr>
<th >           </th>
<th> Hardlinks  </th>
<th> Softlinks  </th>
<tr>

<tr>
<td> command </td>
<td> ln      </td>
<td> ln -s   </td>
</tr>

<tr>
<td> performance </td>
<td> faster      </td>
<td> slower      </td>
</tr>

<tr>
<td> have a file type </td>
<td> no               </td>
<td> yes              </td>
</tr>

<tr>
<td> reach across filesystems </td>
<td> no                       </td>
<td> yes                      </td>
</tr>

<tr>
<td> to directories </td>
<td> only by root   </td>
<td> yes            </td>
</tr>

</table>

</div>


</div> 
</body>
</html>